usb: device_next: hid: add a suspend callback #99123
Conversation
Add an optional suspend callback to let a downstream hid driver be notified of HID suspend and resume events. Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
|
@jfischer-no using this on an hid device to detect when the host goes into suspend, is this the right thing? Can't quite tell it from the controller apis apparently. |
|
tmon-nordic
left a comment
tmon-nordic
left a comment
There was a problem hiding this comment.
I like this approach better than relying on USB notifications in the application, because here the call is synchronous and therefore the state never gets out-of-sync.
Ok... what notifications are you referring to though? |
zephyr/subsys/usb/device_next/usbd_core.c Line 154 in df8b43d zephyr/subsys/usb/device_next/usbd_core.c Line 160 in df8b43d |
|
@tmon-nordic ok but I think |
No, they are the same. The difference is that zephyr/subsys/usb/device_next/usbd_msg.c Line 38 in df8b43d when CONFIG_USBD_MSG_DEFERRED_MODE is not enabled.
|
Ok very interesting, well, this is cheap enough and works reliably then... Thanks for the pointers. |
This is nonsense again. The default mode is the way to provide notifications in a sequential way and not block the USB stack thread. |
| /** | ||
| * This callback is called when the HID interface is suspended by the | ||
| * host. This callback is optional. | ||
| */ | ||
| void (*iface_suspended)(const struct device *dev, const bool suspended); | ||
|
|
There was a problem hiding this comment.
An interface cannot be suspended, and there is nothing like that in the HID specification. To get notifications when a USB device is suspended, please use USBD_MSG_SUSPEND and USBD_MSG_RESUME. There is no reason to have additional callbacks in each function/class implementation.
There was a problem hiding this comment.
An interface cannot be suspended, and there is nothing like that in the HID specification. To get notifications when a USB device is suspended, please use USBD_MSG_SUSPEND and USBD_MSG_RESUME. There is no reason to have additional callbacks in each function/class implementation.
Ok, looked more into my application and yeah actually I managed to get it working with those two messages, the culprit may or may not have been a if (!usbd_can_detect_vbus(usbd_ctx)) {return;} in my code that was causing all messages to be ignored. :-)
Nevermind then thanks for the pointer, guess then these placeholder callback could go? Anyway closing this down.
4 participants
Add an optional suspend callback to let a downstream hid driver be notified of HID suspend and resume events.